fix(sounds): de-duplicate notification sounds across browser tabs - #831

Why

A player with several tabs open heard the same notification sound from every tab at once — each tab holds its own websocket and independently reached playSound(). This de-duplicates playback so exactly one tab beeps.

How

Tabs race for a Web Lock keyed by the sound id (navigator.locks.request(soundId, { ifAvailable: true }, …)). The winner plays; everyone else gets null back and skips. The lock is held ~250ms after playing so that tabs reacting to the same websocket message lose the race, while a notification arriving later still gets through.

playSound() resumes the audio context before racing and drops out if it isn't running. That means a tab which can't unlock its audio never wins the lock and swallows the notification — and, for free, the focused tab usually wins, since its context is already running while a backgrounded tab has to spend a resume first.

If navigator.locks is unavailable (older Safari), it degrades to the previous "all tabs play" behaviour — the same baseline as BroadcastChannel, which the mention path still uses.

The mention clear path broadcasts over a BroadcastChannel, so reading chat in one tab clears the sound, the ★ title prefix and the tab badge in the others. The sound half matters most because that clip is ~6s where the rest are ~1.5s.

Scope / notes

• Applies to all four notification sounds (mention, ready-up, substitution, fight).
• playSound() now requires the element to carry an id — it is the lock key. All four sound elements have one and every call path resolves via getElementById, but an id-less [data-sound-src] element would now stay silent.
• No new telemetry: existing capability metrics (audioReady → audio_blocked_players.count, ready_up.notified.count{audioBlocked}) stay valid; there is no client→server actuation signal and this adds none.
• No automated tests: the front-end has no unit-test harness (vitest runs on node, no DOM env), and Playwright cannot observe real audio output. The lock mechanism itself was checked out-of-tree by driving three tabs of one browser profile — simultaneous burst plays exactly once, a later notification still plays, distinct sounds don't block each other. Audio verified manually: two tabs, one beep; clearing in either tab stops the mention and drops the star in both.
• Desktop-notification duplication (new Notification() with no tag) is a separate, trivial follow-up.

History

The first pass coordinated over a BroadcastChannel election — each tab announced a claim, waited a 60ms window to collect competitors, and the highest-ranked (focused > visible > hidden) played. That was replaced because hidden pages clamp setTimeout to ~1s, which is exactly the scenario the feature targets: the player is alt-tabbed into TF2 waiting on ready-up, so every tab's claim window stretches and the beep lands late. Web Locks put no timer on the latency path, release automatically if a tab crashes, and the priority ordering they give up was inaudible anyway — the tabs share the same speakers.